Release 10.1A: OpenEdge Getting Started:
OpenEdge Reference Architecture
Model components
In the Presentation Layer of the OpenEdge RA, Model components are responsible for the management and communication of data between the user interface and the Business Servicing Layer of the application. Model components serve as the primary means of managing data requirements for one or more View components. They generally map closely to the events that occur within View components.
The Interface contract
In the OpenEdge Reference Architecture, data responsibilities are split between the Presentation Layer and the Business Servicing Layer. The Presentation Layer is responsible for user interaction, feedback, and exception handling, while the Business Servicing Layer is responsible for the marshalling of data to the Presentation Layer and proper processing of data based upon business rules.
In order for the Presentation Layer to function properly with the Business Servicing Layer, there must be an agreed upon structure for the data passed between the two layers. This structure is commonly referred to as an Interface Contract. The Model components within the Presentation Layer are responsible for the Presentation Layer management of data, and therefore must understand the way in which data is passed from the Business Servicing Layer. This not only includes the structure of the data, but also the methods and technologies used for communication.
One of the most common methods for addressing the communication needs of the layers of the OpenEdge Reference Architecture is by designing a consistent set of service interfaces for the application. See the "Service interfaces" section.
Mapping Model to View components
Each View component typically has at least one Model component that it relies on for client data. While it is possible to have View components without associated stored data (a simple alert box, for example), these cases are rare.
It is possible for a Model component to be used by more than one View component in a Presentation Layer. Model components should be designed to promote reusability within the Presentation Layer.
Properties of a Model component
The number and types of properties for a given Model component will likely vary based upon the needs of an application and the Presentation Layer. Properties are commonly used to store instance information relating to the component at run time, allowing for multiple instances to be used.
In certain cases, properties can be used to identify which View component a Model component is interacting with at a given point in the application, allowing for specialized logic within the Model component to be used. For example, a Model component can only request summary customer data from the Business Servicing Layer when being used by an Order Inquiry View component. When interacting with a Customer Maintenance View component, the same Model component could request detailed customer information.
Routines of a Model component
The routines of a Model component are generally designed to:
- Map to specific events in a View component. A routine named
Refresh_Data, for example, could be used whenever a View component (and the user interface) has an event requesting a newer set of data. See the "View components" section for more information about View components.- Map to specific events in a Controller component. See the "Controller components" section for more information about Controller components.
- Map to specific interactions with the Business Servicing Layer. Routines of this type are designed to request and receive data.
|
Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |